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JPL TECHNOLOGY TRANSFER DEFINITION 


. THE TRANSFER OF ORGANIZED KNOWLEDGE TO A PROJECT 
OR PROGRAM FOR THE EVENTUAL PURPOSE OF PRODUCING 
NEW OR IMPROVED, PRODUCTS, PROCESSES OR SERVICES. 

• TRANSFER WILL OCCUR THROUGH ONE, OR MORE, OF THE 
FOLLOWING MODES: 

• OCCASIONAL CONSULTING 

• DOCUMENTATION (REPORTS, ASSESSMENTS, PROGRAMS, 

OR DRAWINGS) 

• TRAINING (ON-THE-JOB, ON-SITE OR ELSEWHERE) 

• DEMONSTRATION (PROOF-OF-PRINCIPLE OR APPLICATION 

TO A REAL-WORLD PROBLEM) 

• COLLABORATIVE TECHNICAL WORK. 
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JPL traditional technology transfer 



TOO OFTEN R &D HAS B EEN CONTENT TO 
THROW ITS PRODUCT OVER THE WALL AND 
HOPE SOMEONE WILL CATCH IT.* 


JPL "BOTH SIDES OF THE FENCE" 



. TECHNICAL MANAGEMENT WITH ASSISTANT 
ENGINEERS _ 

• WORK PERFORMED BY SPECIALISTS AND 
TECHNOLOGISTS 

. FLEXIBLE OPERATIONS AND INTERACTION 

• TIGHT CONTROL POSSIBLE 

• SMALL THROUGHPUT AND VOLUME 

• LOW INERTIA 

. DEDICATED ATTENTION 

• JUDGEMENT CRITERIA 

• EXTENSIVE REWORK PRACTICAL 

• FLEXIBLE EQUIPMENT 

. LITTLE DOCUMENTATION - DATA INTENSIVE 
. COST NOT PRIMARY 

• CHANGES ROUTINE, EASILY IMPLEMENTED 

• REAL-TIME ANALYSIS, TRACEABILITY, AND 
FEEDBACK 

. QA SEPARABLE FUNCTIONS 


• PRODUCT MANUFACTURING MANAGEMENT 
WITH SUSTAINING ENGINEERING CORE-* 

• WORK DONE BY ENGINEERS AND TRAINED 
PERSONNEL 

• ORGANIZED PRODUCTION 

• MANUFACTURING TOLERANCE NECESSARY 

• LARGE THROUGHPUT AND VOLUME 

• HIGH INERTIA 

• LARGE BATCH •’PHILOSOPHY" 

• PASS/FAIL CRITERIA 

• REWORK DISRUPTIVE, UNINTERRUPTED 
FLOWS, STAGING DELAYS 

. NARROW LATITUDE, SEVERAL SHIFT 
CONTINUOUS OPERATIONS SYSTEMS 

• EXTENSIVE DOCUMENTATION - DATA / 
OPERATIONS INTENSIVE 

• COST PRIMARY 

. CHANGES DIFFICULT TO IMPLEMENT 

• NON-ROUTINE ANALYSIS DIFFICULT, 
FEEDBACK DELAY RESULTS IN LOSSES 

• QA NECESSARILY INTEGRAL 


THH-4 


R4-2 


ill II 



JPL IMPLICATIONS OF TECHNOLOGY MATURITY 


MATURE 


DRIVEN BY COST REDUCTION 
PRESSURE ON MARGINS 
BARRIERS TO CHANGE 
ADVANTAGE TO CHALLENGERS 


GROv 



DRIVEN BY MARKET RESEARCH 
PRESSURE ON SPEED 
BARRIERS TO ENTRY 
ADVANTAGE TO MARKET LEADER 


DRIVEN BY PROBLEM RESEARCH 
PRESSURE ON NARROWING OPTIONS 

BARRIERS TO RISK TAKING thh-3 

ADVANTAGE TO ENTREPRENEUR 


JPL. SIMPLIFIED LOOK AT BOTH SIDES 


ISSUE 


TECHNOLOGY OR ADVANCED 
DEVELOPMENT 


IMPLEMENTATION OR 
PRODUCTION 


• MANAGEMENT 

• STAFFING 

• THROUGHPUT 

• INERTIA 

• DOCUMENTATION 

• COST 


• TECHNICALLY ORIENTED 

• TECHNOLOGIST AND SPECIALISTS 

• SMALL 

• LOW 

• MINIMAL 

• NOT PRIMARY 


• PRODUCT ORIENTED 

• ENGINEERS AND PRO- 
DUCTION PERSONNEL 

• LARGE 

• HIGH 

• EXTENSIVE 

• PRIMARY 
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JPL TOMORROW’S TECHNOLOGY TRANSFER 


CULTURE OF BOTH 
ORGANZIATIONS 


CAPABILITIES OF THE 
R&D ORGANZIATION 


CAPABILITY OF USER 
ORGAN IZATION(S) 


NEEDS OF THE 
USER 

. ORGANIZATION 


CHARACTERISTICS OF 
THE TECHNOLOGY 


BARRIERS 

TO 

5 TECHNOLOGY 
TRANSFER 



TRANSFER 

.SUCCESSES 


JPL Barriers 

• The user community lacks a process to identify common technology 
requirements 

• The user community lacks a vehicle to exert the collective leverage to 
cause J PL/NASA to implement co mm on design. 


• Resources invested in existing systems and applications, and the 
attitude and culture of the work force make it difficult to evolve to new 
technologies. 


• Current practices encourage a tactical approach to solving technical 
problems while ignoring key strategic (i.e. long term) issues. 


• There are inadequate incentives fostering the insertion of new 
technology In to new missions. The linkage between technology payback 
and achieving missions goals is not strong. 


• Fear of being unable to complete a mission (on-time, within budget, and 
meeting mission goals) using “newer” technology. 


• There is no documented, coherent JPL/NASA vision for broad-based 
technology integration and the role of technology transfer in achieving 
that vision. 
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JPL 


Barriers (cont'd) 


• There is no shared vision for developing a technology transfer process. 

• Transfer is further complicated by the fact that oft times capabilities 
rather than specific products must be transferred. 

• With today’s projects, you cannot simultaneously accept a 
“fixed-priced” contract from Congress to develop a major undertaking 
and at the same time support technology development and the 
unavoidable attendant risks, i.e. cost uncertainty. 

• Inadequate staffing by engineering. A common response to the 
suggestion for new technology is “We do not have anyone here who has 
the technical skills and knowledge to incorporate this technology into 
current projects.” 

• The perception that a technology is too complex will often lead the 
Intended users to question the technology developers credibility. 

• NASA does not develop serious plans beyond a five year new start 
horizon 
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JPL TECHNOLOGY READINESS LEVELS 


BASIC TECHNOLOGY RESEARCH 


RESEARCH TO PROVE TECHNICAL 
FEASIBILITY 


TECHNOLOGY DEVELOPMENT 


TECHNOLOGY DEMONSTRATION 


LEVEL 1 BASIC PRINCIPLES OBSERVED AND REPORTED 

_LEVEL 2 TECHNOLOGY CONCEPT AND/OR APPLICATIONS FORMULATED 

"level 3 ANALYTICAL & EXPERIMENTAL CRITICAL FUNCTION AND/OR 
CHARACTERISTIC PROOF-OF-CONCEPT 

LEVEL 4 COMPONENT AND/OR BREADBOARD VALIDATION IN LABORATORY 
ENVIRONMENT 


SYSTEM/SUBSYSTEM DEVELOPMENT 


SYSTEMS TEST AND OPERATIONS 


LEVEL 5 COMPONENT AND/OR BREADBOARD VALIDATION IN A RELEVENT 
“ ENVIRONMENT (GROUND OR SPACE) 

LEVELS SYSTEM/SUBSYSTEM MODEL OR PROTOTYPE DEMO IN A 
SIMULATED ENVIRONMENT (GROUND OR SPACE) 

LEVEL 7 SPACE PROTOTYPE DEMONSTRATION IN A SPACE ENVIRONMENT 


LEVEL 8 ACTUAL SYSTEM COMPLETED AND -RIGHT QUALIFIED - THROUGH 
“ TEST AND DEMO (GROUND OR SPACE) 

LEVEL 9 ACTUAL SYSTEM "FLIGHT PROVEN" THROUGH SUCCESSFUL 
MISSION OPERATIONS 


THH-7 


R4-5 


JPL SOFTWARE TECHNOLOGY READINESS LEVELS 

(PROPOSED) 


t BASIC TECHNOLOGV RESEARCH_| 

RESEARCH TO PROVE TECHNICAL 
FEASIBILITY 


TECHNOLOGY DEVELOPMENT, 


TECHNOLOGY DEMONSTRAVONj 


SY^EI^UBSYSTCM^EVELOPI^ml 


"LEVEL 1 NEW BASIC PRINCIPLES/SOLUTION METHODS REPORTED 

LEVEL 2 CONCEPTUAL DESIGN FORMULATED 

""LEVEL 3 CONCEPTUAL DESIGN VALIDATED ANALYTICALLY OR VIA 
SIMULATIONS 

LEVEL 4 CRITICAL FUNCTION/ALGORITHM DEMONSTRATED 

LEVELS CRITICAL COMPONENT PHOTOTYPE TESTlDTNlSELEVANT 
ENVIRONMENT 

LEVEL 6 PROTOTYPE ENGINEERING MODEL TESTED IN OPERATIONAL 
_ ENVIRONMENT 

LEVEL 7 ENGINEERING MODEL TESTED IN OPERATIONS 
LEVEL « PULL FLIGHT CAPABILBITY (INCORPORTED IN PRODUCT) 


SYSTEMS TEST AND OPERATIONS 


LEVELS 


ACTUAL SYSTEM "FLIGHT PROVEN" THROUGH SUCCESSFUL 
MISSION OPERATIONS 
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JPL TECHNOLOGY TRANSFER MATRIX 

(FROM A STUDY) 


EQUIVOCALITY 


HIGH- 


LOW 


BLACK 

HOLE 


| 

2 


DEAD IN 
THE WATER 


GRAND 

SLAM 


UJ 

0 

z 

1 

o 


LONG 

SHOT 


LOW* 


-HIGH 


COMMUNICATION 
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JPL WHY? - PART OF THE ANSWER IS THE 
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ACCOUNTABILITY 


WHY? - DIFFERENT VIEWS OF TECHNOLOGY 

JRL -READINESS" ARE ALSO A PROBLEM 




TECHNOLOGY READINESS LEVELS 
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IPL FUNDING PROFILE DURING 
TECHNOLOGY TRANSFER 



TIME 
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JPL NASA TECHNOLOGY TRANSFER INTERFACES 




INDUSTRY/ 

ACADEMIA 




IMPLEMENTING 

COMPANY/ 

UNIVERSITY 
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JPL 


KEY FACTORS 


• PLANNING 

. USER INVOLVEMENT 

• COMMUNICATIONS 

• A PROCESS IS REQUIRED 

• KNOW ING AND ASKING THE RIGHT QUESTIONS 
. RESPONSIBILITY AND ACCOUNTABILITY 

. FUNDING : - 1 
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JPL TECHNOLOGY TRANSFER PROCESS 



TECHNOLOGIES ON-G OING PROGRAM 


ANNUAL 

OPERATING 

CYCLE 



END-USER ACCEPTANCE 


* FUTURE ACTIVITY, 

NEED NOT BE DONE INITIALLY 
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JPL 


THE DO'S 


• TREAT THE TECHNOLOGY TRANSFER AS A PERSONAL COMMITMENT. IT IS PEOPLE THAT MAKE 
PARTNERSHIPS WORK 

• ANTICIPATE THAT IT WILL TAKE UP MANAGEMENT TIME. IF YOU CAN NOT SPEND THE TIME, DO NOT 
START THE TRANSFER 

• MUTUAL RESPECT AND TRUST ARE ESSENTIAL. IF YOU DO NOT TRUST THE PEOPLE YOU ARE 
WORKING WITH, FORGET IT 

• REMEMBER THAT BOTH PARTNERS MUST GET SOMETHING OUT OF IT. MUTUAL BENEFIT IS VITAL. 
THIS WILL PROBABLY MEAN THAT YOU HAVE GOT TO GIVE SOMETHING UP. RECOGNIZE THIS AT 
THE OUTSET 

• DO NOT PUT OFF RESOLVING UNPLEASANT OR CONTENTIOUS ISSUES UNTIL "LATER" . 
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JPL THE DO'S (contd) 


■ RECOGNIZE THAT DURING THE COURSE OF THE TRANSFER/COLLABORATION, CIRCUMSTANCES AND 
MARKETS CHANGE. RECOGNIZE YOUR PARTNER’S PROBLEMS AND BE FLEXIBLE 

• MAKE SURE THAT YOU AND YOUR PARTNER HAVE MUTUAL EXPECTATIONS OF THE TRANSFER AND 
ITS TIME SCALE 

• GET TO KNOW YOUR OPPOSITE NUMBERS AT ALL LEVELS 

■ APPRECIATE THE CULTURAL DIFFERENCES. DO NOT EXPECT A PARTNER TO ACT OR RESPOND 
IDENTICALLY TO YOU 

• RECOGNIZE YOUR PARTNER'S INTERESTS AND INDEPENDENCE 
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JPL 


MEASURE YOUR BOSS'S RDQ 


THE RDQ (RESEARCH AND DEVELOPMENT QUOTIENT) WAS ORIGINALLY 
DEVELOPED BY WARREN LUSHBAUGH TO EVALUATE JPL ENGINEERS, 
GROUPS, SECTIONS, ALDs... 


DEFINITION: 

RDQ = 10 LOG 
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1.0 Introduction 


At its worst, traditional technology transfer is “tossing the good ideas over the wall to 
engineering” (see Figure 1). The ideas are not “caught" by the people on the other side; the 
results: missed opportunities; the technology developer is isolated from the intended user; the 
technology developer certainly does not know where the user is going; and the intended user does 
not know the new technology is coming. No wonder that these ideas are not “fielded" by the 
intended user. 

At its best, technology transfer is the process by which both the intended user and technology 
developer get what they want and need. The user receives new or needed capabilities. The 
technologist receives recognition, continued funding, satisfaction or the like. 



TOO OFTEN RAD HAS BEEN CONTENT TO 
Tl IROW ITS PRODUCT OVER THE WALL ANO 
HOPE SOMEONE WILL CATCH IT.' 

Figure 1 Traditional Technology Transfer 


It may be said, that the Space Exploration Initiative (SEI) has a planning window of today 
through 2025, or ten years beyond initial long-term presence on Mars. Critical to the success 
of these long-lived programs is the ability to remain technologically viable during this extended 
development and mission-operations era. When the capabilities of terrestrially deployed 
systems are increasing by an order of magnitude every five to ten years, computers every three 
to four years, and detectors every two years, what does it mean to design systems for programs 
that require ten years to develop and have a life expectancy of up to 35 years? There are a 
number of obvious options: (1) Freeze the technology and stash a lifetime of spares, (2) plan 
for a complete replacement every five to seven years, (3) ignore the need for change and let the 
future take care of itself, or (4) plan to evolve the system. Only the fourth option suits the 
missions’ purposes. 

From a JPL point of view, these decadal missions map into the need to consistently and rapidly 
move the results of research and development into main stream mission development. For JPL 
survive and prosper, upgrading of technology must be a vital part of each mission. At present, 
JPL’s technology utilization spans a dizzying range from 1970’s to 1990's technology. These 
are all significant drivers leading to the realization that a more formal technology transfer 
process is needed at JPL 
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This paper will discuss the requirements for a successful technology transfer program and what 
such a program would look like. In particular, this paper will address the issues associated 
with technology transfer in general, and within the JPL environment specifically. 

The balance of the paper is in two Sections, i.e. Background and Technolog y Tran sfer. Section 2,, 
Background, will (1) set the stage, (2) identify the Barriers to successful technology transfer; 
and (3) suggest Actions to address the Barriers either generally or specifically. Section 3, 
Technology Transfer, will present a process with its supporting management plan that are 
required to ensure a smooth transfer process. 

If the reader is interested only in the process, the Background Section may be skipped ... thus, 
you may proceed directly to Section 3. 


2.0 Background 


Technology transfer may be defined as 

the transfer of organized knowledge to a project/program for the 
eventual purpose of producing new or improved, products, 
processes or services. Tr ansfer w ill occur through one, or more, 
of the following modes: occasional cons ulting, documentation 
{reports, assessments, programs, or drawings), training 
(on-the-job, on-site or elsewhere) , demonstration 
(proof-of-principle or application to a real-world problem), and 
collaborative technical work. 

Given this definition, it is obvious that technology transfer is absolutely dependent on person- 
to-person communications and is affected by all those things which encourage or inhibit 
communications, such as need, funding or confidence. 


One important observation is that, in general, most "new" products are in fact improved 
versions of products that were available last" year. They are based, not on a brand new idea 
from science, but on improving an existing product. And the process of repeated incremental 
improvement that produces these new versions of the product is inherently resistant to ideas 
from outside itself. Figure 2, details some of the implications of Technology Maturity. Thus, it 
is important to have a routine mechanism for inserting these technology improvements into the 
development cycle. ^ 

It does not take too many missed opportunities before both sides start losing interest in the 
whole process. Missed handoffs have the potential of large impacts on the projects. Thus, what 
we need are clear mechanisms (viz procedures, processes) with their associated management 
and cultural infrastructures, that enable reliable, consistent, and successful technology 
transfers. 

Embedded within this mechanism is the recognition that the attributes, needs, etc for each of the 
organizations have different drivers e.g. cultural, motivation or rewards systems (see Figure 
3). For example, in advanced development, documentation only need be adequate for individuals 
intimately involved in the technology, whereas, in implementation, documentation is paramount 
in the organizations ability to provide reproducible, standard products. 


R4-16 


Mature 




Driven by mark* research 
Pressure on spaed 
Barriers to entry 
Advantage to market l e ader 


Driven by problem research 
Pressure on narrowing options 
Barriers to risk taking 
Advantage to entrepreneur 


Figure 2 Implications of Technology Maturity 


Advanced Development 

• Technical Management with assistant engineers 

• Work performed by specialists and 

technologists 

• Flexible operations and interaction 

• Tight control possible 

• Small throughput and volume 

• Low inertia 

• Dedicated attention 

• Judgement criteria 

• Extensive rework practical 

• Flexible equipment 

• Little documentation • data intensive 

• Cost not primary 

• Changes routine, easily implemented 

• Real-time analysis, traceability, and feedback 

• QA separable functions 


Implementation or Production 

• Product manufacturing management with 

sustaining engineering core 

• Work done by engineers and trained personnel 

• Organized production 

• Manufacturing tolerance necessary 

• Large throughput and volume 

• High inertia 

• Large batch "philosophy" 

• Pass/Fail criteria 

• Rework disruptive, uninterrupted flows, 
staging delays 

• Narrow latitude, several shift continuous 

operations systems 

• Extensive documentation - data/operations 

intensive 

• Cost primary 

• Changes difficult to implement 

• Non-routine analysis difficult, feedback delay 

results in losses 

• QA necessarily integral 


Figure 3 "Both sides of the fence" 1 


1 “Technology: Development to Production:, J. L. Abita, IEEE Transactions on Engineering 
Management, Vol EM-32, No. 3, August 1985, pp 129-131. 


R4-17 


We may establish an alternative view of Figure 3 by observing the relationships as depicted in 
Figure 4. This view enables a view of categories of issues as they relate to advanced 


development or production. 

Issue 

• Management 

• Staffing 

• Throughput 

• Inertia 

• Documentation 

• Cost 


Technolo gy or Advanced 
Development 

• Technically oriented 

• Technologist and specialists 

• Small 

• Low 

• Minimal 

• Not primary 


Implementation or 
Production 
< Product oriented 

• Engineers and production 

personnel 

• Large 

• High 

• Extensive 

• Primary 


Figure 4 Simplified Look at Both Sides 

The technology transfer process of tomorrow (Figure 5) must provide the environment to 
enable the identification of new requirements, emerging technologies with their forecasts, and 
insight into organizational capabilities. Thus, as technology items are developed, another 
process (outside the normal research process) is required to assure that these items have a 
reasonable chance of transfer to the end user. The environment established by the process must 
support and be sensitive to all the drivers in each organization, viz. their needs, their 
technology characteristics, their production capabilities. 


2.1 Technology Rea diness Levels 


NASA’s standard Technology Readiness Levels are depicted in Figure 6. For technology jejited 
issues, levels 1 through 7 are used. The additional two levels ( 8 and 9 ) are presented for 
completeness, i.e. to show the full development cycle. The levels are annotated to show the 
higher level relationships among the activities. In general, technology transfer occurs at the 
Technology Demo nstration Level. 

These definitions of readiness levels are just one way to characterize the complex technology 
development cycle. One must remember that this taxonomy is for general referep ^. The leye s 
are to provide common ground or a context for the technologists and target users to establish 
mutual understandings. These levels should not be used slavishly, without thought, foMhen, 
they become an additional barrier to successful technology transfer. For example, co nsider t he 
readiness levels are reflected in figure 7. This characterization is attempting to better descnbe 
a software-intensive technology development, whereas the standard readiness levels are more 
systems and hardware oriented. Although I took the liberty to annotate the software readiness 
levels with the same cycle descri ption, there do remain numerous questions as to their mapping 
the same way as the standard readiness levels. 


Differences in technology transfer can and do occur based on the level in the system hierarchy, 
viz from components to full subsystems. 

Additionally, technology at one end of the continuum may have a very narrow (or even single) 
target user, whereas at the other end, the technology may have broad, generic applicability. 


Programs have the option of tackling key technology earlier if the technology is mainstream to 
their mission. Thus, these levels are used as guidelines in preparing for the eventual insertion 
of new technology into mainstream use. 
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Figure 5 Technology Transfer - Tomorrow 2 
Technology Readiness Levels 


Baste Technolog^Research 

Research to Provo Technical 
Feasibility 


_j Level 1 Basic Principles Observed and Reported 

Level 2 Technology Concept and/or Applications Formulated 


Technology Development I 


Technology Demonstraton 


System/SubsvstemDevelopment I 


Oysisms Isst and QuatsHoos 


Level 3 Analytical & Experimental Critical Function and/or 
Characteristic Proof-of -Concept 

Level 4 Component and.or Breadborad Validation in Laboratory 
Environment 

Level 5 Component and/or Breadboard Validation in a Relevant 
■ Environment (Ground or Space) 

Level 6 System/Subsystem Model or Prototype Demo in a Simulated 
Environment (Ground or Space) 

Level 7 Space Prototypte Demonstration in a Space Environment 

Level 8 Actual System Completed and "Flight Qualified" Through 
_ Test and Demo (Ground or Space) 

Level 9 Actual System "FNght Proven* Through Successful Mission 
Operations 


Figure 6 Technology Readiness Levels 3 


2 “Transferring New Technologies From R&D to Manufacturing,” W. E. Souder and V. 
Padmanabhan, Research • Technology Management, September-October 1989, pp 38-43. 

3 See the Appendix for a narrative description of these levels. 
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Software Technology Readiness Levels . 
(Proposed) 


Basic Technology Research 

Research to Prove Technical 
Feasibility 


Technology Development 


Technology Demonstraton 


System/SubsystemDevelopment I 


Systems Test and Operations 


Level 1 
Level 2 
Level 3 
Level 4 
Levels 
Levels 

■ 

Level 7 
Level 8 
Levels 


New Basic Principles/Solution Methods Reported 
Conceptual Design Formulated 

Conceptual Design VaBdated Analutically or via Simulations 

Critical Function/Algorithm Demonstrated 

Critical Component Prototype Tested in Relevant Environment 

Prototype Engineering Model Tested in Operational 
Environment 

Engineering Model Tested in Operations 

Full Right Capability (Incorported in Product) 

Actual System "Flight Proven" Through Successful Mission 
Operations 


Figure 7 (Proposed) Software Technology Readiness Levels 4 

2*2 A M odel fo r Te chnology Trcnsfgi 5 

A study at the Microelectronics and Computer Technology Corporation® focused on seven aspects 
of technology transfer: effectiveness of technology transfer at the consortium; effectiveness of 
various methods for technology transfer; Imp ortance o f var i ous factors in f ac ilitating the 
technology transfer process; importance of barriers to technology transfer at both the^^ 
consortium and the shareholder companie s; a gr eemen t on who should set the research agenda; 
agreement on the type of research in which the consortium should be engaged; and agreement on 
ways that the consortium could improve the technology transfer process. 

Based on this research four key variables emerged as especially critical in the technology 
transfer process: communication, motivation, distance, and technological “equivocality” (see 
Figure 8 Technology Transfer Matrix). 

In Figure 8, each of the quadrants is discussed in the following: 


4 “Technology readiness levels for Software", Robert C. Tausworthe, JPL IOM dated March 7, 
1990. 

5 “Accelerating Technology Transfer in R&D Consortia", R. W. Smilor and D. V. Givson, 
Research • Technology Management, January-February 1991, pp 44-49. 

6 A major, for-profit, U.S R&D consortium that was established in 1983. 
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Communication • Both passive and active communications are involved in 

communications between technology developers and technology users. Passive 
communications have a broad sweep and are usually media-based. Here, greater care 
may be taken in packaging and producing a quality message. 

Active links are direct, person-to-person interactions. They may range from 
teleconferences to ad hoc teams and onsite demonstrations. The benefits of active 
links center on the fact that they encourage interpersonal communications in terms of 
fast focused feedback, i.e. the researcher learns from the potential user and vice 
versa. 

The fewer and more passive the links, the less likely the chance that technology will 
be successfully transferred. The higher or more active the communication links, the 
more likely the chance of technology transfer. 

At JPL, communication is particularly important in that as large projects change 
their mission design or switch to an entirely different mission, the technology 
developers will be left with unnecessary or unneeded technology developments. This 
just leads to the need for clear, continuous communication. From this, it is also true 
that all this requires robustness to accommodate (or survive) change. 
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Figure 8 Technology Transfer Matrix 

Distance - The second variable - distance - involves both geographical and cultural 
proximity or separation. Essentially, the result here Is that the manager should 
endeavor to "co-locate" technology developers and their customers via promoting 
more active and direct communications links. (See Appendix A for additional 
information) 
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“Equivocality" 7 - This refers to the level of concreteness of the technology. Technology 
that is low in equivocality is fairly easy to understand, demonstrable and 
unambiguous. There is only one meaning to every individual involved in the 
technology transfer- the technology is understandable and its application clear. Of 
course, the higher the equivocality of the technology, the more difficult it is to educate 
the prospective users on the value or application of that technology. Clearly, this is 
part of the problem associated with communication. 

Motivation - This involves incentives for and recognition of technology transfer. 
Motivation varies by importance of the technology transfer In the culture of an 
organization, the criteria by which the individual is evaluated, and the rewards 
established for those who engage in technology transfer activity. 

Motiv atio n means there is a definite answer to the question “What is in it for me?" 
when asked by the technology users and developers. 

One can tell from the selection of the abscissa and ordinate axes labels that Motivation and 
Communication are the dominate factors in a successful technology t ransfe r. As indicated above, 
perceptions of the maturity of the technology are directly related to the ability of the 
participants to communicate. 

In the final analysis of this model, it would seem, at least from a JPL/NASA point of view, that 
one significant missing factor is cost or affordability. Fiscal considerations play a key role in 
both technology development and acceptance. 

Technology transfer is “Dead in the Water when there is low communication, low motivation, 
high distance, and high equivocality. The participants do not talk with each other because there 
are neither the incentives nor recognitions for those involved, because they are separated 
geographically, and because the technology is ambiguous and the application is uncertainl 

What we want at JPL is the “Grand Slam.“ To achieve this we need high communication, high 
motivation, low distance, and low equivocality. In other words, because of highly interactive 
communication processes, because of a variety of incentives and recognition, and because the 
technology is unambiguous and its applications understood, successful technology transfer 
occurs. Of course, given JPL’s relationship to NASA, all this must occur at NASA HQ also. 

2.3 Barriers 

Many of the barriers result from the fact that at any given time, no one is really focusing on 
what the next-step-after-this-version would be, that is to say: researchers are doing far-out 
exploratory work; a portion of development is producing the new systems required by the 
current missions; the balance of development is readying the next version for a continuing 
mission. 

“Additionally, our factories and other workplaces have long been designed around management 
principles that prevent organizational flexibility and change. Harvard's Michael Porter 
describes it well: 'Change is an unnatural act, particularly in successful companies; powerful 
forces are at work to avoid and defeat it. Past approaches become institutionalized in standard 
operating procedures and management controls. Training emphasizes the one correct way to do 
anything; the construction of specialized, dedicated facilities solidifies past practice into 


7 Equivocality is defined to be - of doubtful advantage, or subject to interpretation. 
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expensive brick and mortar...' Such systems were simply not designed to react quickly, if at 
all, to rapidly changing conditions.* 8 

Many would say that a fundamental problem in technology transfer is the lack of a way to bridge 
the technology transfer gap (Figure 9). 



Figure 9 Technology Transfer Funding Gap 
This gap is caused by two factors 

(1) Historically, research is complete when a breadboard article has been validated. 

This validation, which occurs somewhere in readiness level 4, usually signals the 
termination of research funding (such as Code R). 

(2) Unless the technology is fundamentally enabling to an endeavor, the flight project or 
consumer is usually hesitant to incorporate a new technology without the existence of 
an engineering model, at the very least. Additional confidence is built with the 
demonstration of the engineering model in an environment similar to the intended 
usage. Thus, users support (such as Code S) generally is not available until the 
technology reaches readiness level 6. 

These two factors clearly indicate that each organization needs to recognize that 
co-accountability is the only way to affect the smooth insertion of this new technology in to 
mainstream usage. The Technology Transfer Plan is a vehicle to formalize this 
co-accountability and its eventual transfer to the using organization. In particular, the funding 
profile to bridge this gap Is important (see Figure 10). The plan will document the transition 
funding profile required for successful handoff. Some of the issues facing technology transfer 
are beyond the scope of a single center. There needs to be a more complete technology transfer 
process that includes all the NASA centers and Codes S and R within NASA itself. Figure 1 1 , 
NASA Technology Transfer Interfaces, depicts the needed interactions at various levels, i.e. 
starting with industry and academia through the Associate and Administrator level of NASA. 
Without explicit support within Code S for technology development/transfer activities, it will 
be difficult to Insert new technology into on-going or new programs. This Code S funding 


8 “Technology Development in the 1990s: Will Government Polices Help or Hinder?", Speech 
by Robert M. White, Under Secretary for Technology, U.S. Department of Commerce, to Council 
on Superconductivity for American Competitiveness, September 14, 1990. 
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coupled with “good faith" support from the target user and Code R support, will provide the 
basis for successful technology transfers. 



Figure 10 Funding Accountability 



Figure 11 NASA Technology Transfer Interfaces 9 


® Adapted from drawings and ideas of W. J. Weber III at NASA/JPL 
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Yearly exchanges between each column (as illustrated by the horizontal doubled-ended lines) 
would enhance the ability to identity needs (e.g. Code S) and emerging technologies (e.g. Code R). 
As part of this exchange, more cohesive programs of technology development and transfer could 
be established. 

The significant barriers having differing effects are the variables of communication, motivation 
or advocacy, risk or maturity of the technology, and organizational structure (distance). 

Figure 12 lists some of the specific barriers identified at JPL and suggests dominate areas of 
effect. 
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Comm Advoc Mgnt Risk 
XXX 


Barrier 


The user community lacks a process to identify common 
technology requirements 


The user community lacks a vehicle to exert the collective 
leverage to cause JPL/NASA to implement common design. 

X 


X 


Resources invested in existing systems and applications, and 
the attitude and culture of the work force make it difficult 
to evolve to new technologies. 



X 


Current practices encourage a tactical approach to solving 
technical problems while ignoring key strategic (i.e. long 
term) issues. 



X 

X 

There are inadequate incentives fostering the insertion of new 
technology in to new missions. The linkage between 
technology payback and achieving missions goals is not 
stronq. 

X 

X 

X 


Fear of being unable to complete a mission (on-time, within 
budget, and meeting mission goals) using ‘newer* 
technology. 



X 

X 

There is no documented, coherent JPUNASA vision for 
broad-based technology integration and the role of 
technology transfer in achieving that vision. 



X 


There is no shared vision for developing a technology transfer 
process. 

X 


X 


Transfer is further complicated by the fact that oft times 
capabilities rather than specific products must be 
transferred. 



X 

X 

With today's projects, you cannot simultaneously accept a 
fixed -priced" contract from Congress to develop a major 
undertaking and at the same time support technology 
development and the unavoidable attendant risks, i.e. cost 
uncertainty. 



X 

X 

Inadequate staffing by engineering. A common response to the 
suggestion for new technology is "We do not have anyone 
here who has the technical skills and knowledge to 
incorporate this technology into current projects." 



X 

X 

The perception that a technology is too complex will often 
lead the intended users to question the technology 
developers credibility. 

X 

X 

X 


NASA does not develop serious plans beyond a five year new 
start horizon 


X 

X 



Figure 12 Barriers 


2.4 Case .St udies At JPL 

Understanding the current state-of-practice for technology transition at JPL is important. It is 
important to understand the attributes of recent efforts at JPL regardless of their success or 
not. These interviews included both specific insertion efforts and knowledgeable peoples’ 
general understanding and views on technology transfer. The specific efforts at JPL included: 

- Viterbi decoder for Voyager and Galileo 

- Solid state power components e.g. switches, microprocessors 
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- Fiber Optic Rotation Sensor (FORS) 

* Onboard processing for CRAF/CASSINI 

- Rhenium engine, electric propulsion 

- Optical communications. 

These were selected because they are recent and there exists an adequate body of current 
knowledge in order to extract some similarities, principles or guidelines. 

Without identifying the specific task or individual here are some of their insights (these are 
broadly grouped via 

Involvement; 

- Cannot underestimate the value of the advocates/champions. This should be done even 

to the extent of transferring someone with the technology. 

- With advanced technology funding support via Code S, FPO, OSSI, etc, the 

first-use-of-technology-eats-the-cost syndrome may be broken. 

- User involvement is key to the successful transfer of the technology. This enables a 

“buy-in" by everyone. 

- Technologist do not understand the paradigm for technology transfer. User confidence 

is everything. Technologist should consider all potential end-users as from Missouri, 
i.e. "Show Mel". 

Eficua 

- Some efforts have not been successful because the technologist became enamored with 

technology as an end result in itself, thereby losing sight of the needs of the project. 
They focused on the wrong problem from a flight project point of view. 

- JPL has made the mistake of putting the technical person in-charge, where a task 

manager is really needed. The technical support is required. One choice is to possibly 
placed the technologist on staff as the chief scientist, chief engineer, etc. 

- When discussing technology transfer, we really need to understand the drivers. Is the 

project in dire need (technology pull)? Is the technology ripe and there are clear 
applications (technology push)? Is it basic, enable technology, thereby causing the 
user to take the technology earlier than normal (pre-engineering model 
development)? 

- The flight projects have to very conservative because of risk. Users are generally 

unwilling to accept risk in the bus; there is after all only one bus and if it fails, the 
entire mission fails. Thus, the users are interested in new bus technology only if: 

(1) it is mission enabling, i.e. the mission can not be accomplished without this 
technology; and/or (2) it is reasonably mature, having reached the engineering model 
stage and thus represents no more than moderate risk. 

- Flight project should not be involved in technology development. 

- Technical risks in the instruments are often acceptable: a given mission generally 

involves a range of task performed by multiple instruments, so a failure of any one 
instrument does not result in failure of the mission as a whole. 

- Even if a reasonably mature new technology and an interested user find one another, a 

final hurdle remains: the cost of full and final flight development of the technology 
must almost invariably be borne by the first user. The fact that such funding must be 
provided during the trying early years of a flight program makes this last hurdle 
much more difficult. 

Options for making the process a smooth one: 

- Technology does not come in spurts like spacecraft do. We need a continuous program 

(here you may read “real budget") to develop the underlying technology for later 
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insertion. (Comments like this lead to the question of “Why do not OSSI and FPO 
establish technology programs like TDAs?"). 

- A significant portion of the Advanced Technology Development funding from Code S goes 

into advanced mission planning; more should go in to technology planning and 
technology insertion support (bridging funding).-^ - 

- With advanced technology funding support via Code S, FPO, OSSI, etc, the 

first-use-of-technology-eats-the-cost syndrome may be broken. 

- When considering technology transfer, industry's role should be considered, 

particularly since we do not usually build production units. Can synergistic 
relationships be established with institutions such as Draper Labs? 

- If a new technology is to be attractive and ready for use on a given mission, its 

development process must usually start well before the mission itself emerges from 
the pre-project phase. Unfortunately, this implies a chicken-and-egg problem: the 
prospective user in not interested in immature technology, but without user interest, 
it is very difficult to advance a technology to an attractive level of maturity. 

2.5 Actions 

There is a broad spectrum of actions that may be taken to address the barriers to technology 
transfer. These include: 


Involvement: 

- Assign top level champions (bilateral championship). They will be the advocates of 

the technology to the two organizations, i.e. the technology developers and users. They 
will draft and get concurrence on the Technology Transfer Plan. 

- Involve the end user in the early stages of technology development. This involvement 

may range from publication distribution and review participation, to engineering 
involvement in design. This is necessary if the technologists want the potential users 
to ultimately accept the technology rather than disregard it as yet another example of 
“a solution looking for a problem." # 

. Encourage the users to participate in developing the technology. Too often technology 
developers have been content to "t hrow t heir product over the wall and hope someone 

will catch it (Figure i).“ " ••• •” 7 ; 

- Demonstrate the technology to the end user community. Provide opportunities for 

users to meet collectively and share their experiences, requirements and needs. 



- Apply the technology to a few representative problems before attempting to transfer 

it 10 . Thus, the recommendation is to (1) whet the user's appetite by trying the 
technology on one of his applications by the technology developer in the laboratory, 
then showing him how successful it was, (2) invite the user to work on the second 
application, and (3) finally, initiate the transfer process, by letting the user choose 
the next application and start providing the development pull and fiscal support. It is 
here that one may want to consider temporarily transferring a technology developer 
to the project development team. 

Options for making the process a smooth one: 

- Provide training by the technology developers. Often the technology developers lose 

interest after the readiness stage; they do not want to write the users manual or to 


10 Be willing to provide resources (people, time and money) to sell the technology. 
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think about features that may make it easier to use. Effective transfer requires these 
activities. Some accommodation must be formally made to effect this. Also, assisted 
by the technology developers, the consuming organizations need to provide formal 
training to the development engineers. 

- Dedicate an engineer to monitor the transfer. 

- Follow-up to determine the effectiveness of the transfer process. Never say “Good 

bye" - feedback is important to the technology developers to fix immediate problems 
as well as considering improvements for the next round in the technology. The 
transfer process, itself, also needs calibration to enable improvement in the next 
round of technology transfer activities. 

- Identify a host nmtoct- Given the “fixed-priced" mode of flight projects, what could 

help would be an arrangement whereby one or two targeted technology development 
activities would be taken on by a project with the up-front understanding that these 
areas would be excluded from the requirements of the “fixed-priced" constraints. 
Thus, a host project would be identified. This project would be the end-user for the 
technology in question. 

The shotgun approach of overwhelming the barriers with actions/promoters can usually be 
replaced with a more efficient approach of eliminating barriers by matching them with specific 
actions. These actions will be codified via the Technology Transfer Process and its associated 
Technology Transfer Plans. 


3.0 Technology Transfer 

At this point, it is important to restate the definition of technology transfer: 

the transfer of organized knowledge to a project/program for the 
eventual purpose of producing new or Improved, products, 
processes or services. Transfer will occur through one, or more, 
of the following modes: occasional consulting, documentation 
(reports, assessments, programs, or drawings), training 
(on-the-job, on-site or elsewhere) , demonstration 
(proof-of-principle or application to a real-world problem), and 
collaborative technical work. 


Thus, again, given this definition and what has been dismissed previously, it is obvious that 
technology transfer is absolutely dependent on person-to-person communications and is affected 
by all those things which encourage or inhibit communications, such as need, funding or 
confidence. This communications must be between technology developers and the intended 
users, where users include not just the programmatic element, but the intended everyday 
utilizers of this technology. For without the ultimate end-users participation, the technology 
may be transferred, but not used (i.e. the transfer use not really consummated!). 

We must overcome the general barriers associated with communications, motivation, technology 
readiness, and organization structure as described Sections 2.2. and the specific impediments as 
discussed in Section 2.3. Some of the significant factors concerning technology transfer from 
both the giving and the receiving perspectives include: 

(1) Each transfer is really unique in the full sense of the word. The planning must 
address the ripeness of the technology (such as the needs of the receiving community 
or user; the complexity of the technology, that is to say is it a chip set or complete 
subsystem; and the maturity and skills of both organizations). Thus, application 
planning is one key to a successful technology transfer. 
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(2) User Involvement is the next significant factor. Without the active sponsorship and 
support of the “host project", it is probably a case of “a solution looking for a 
problem." 

(3) Since there are at least two organizations involved in the process, continuing, clear 
communication is essential. Open, working, active lines of communications are 
important to the continued ability to work out process and technical issues before they 
become too large to handle. Thus, communications is another key factor to a 
successful technology transfer. 

(4) A process that encourages asking the right questions at the right time is next in our 
list of key factors. There are appropriate questions to be addressed at each stage 
(pre-transfer, planning, readiness review, and active transfer) of the transfer 
process. Often the process is complicated by not asking the appropriate questions. 

(5) There is a real need to address the right questions at each step of the process. 
Knnwinn the Questions and their logical location in the process is also key to the 

process. 

(6) Often a transfer is attempted as a part-time activity or without clear lines of 
accountability. The results are slow or no decisions, lack of follow through which 
leads to frustration and ultimate failure. Clear lines of responsibility and 
arootintahilitv are the next keys to a successful technology transfer. 

(7) Technology transfer becomes a funded activity. Funding is identified to bridge the 
gap between technology availability/demonstration and incorporation into a host 
project. With identified funding sources, technology comes of age in its own right. 

As discussed above, technologies are “ready-for-transfer* at d ifferent stages in their 
development depending on the user’s requirements, state-of-the art, etc. Thus, the process and 
documentation described in this section are only guidelines, and the reality is that each 
technology effort must be reviewed on its own merits. The appropriate level of technology 
readiness for transfer in any one case will depend on the needs and plans of the user organization 
to become involved in the development program and effect the technology transition into 
program and project activities. 

3.1 The Process v ::::: ..... . . ' 

The process should enable a “Grand Slam" (see Figure 8 and Section 2 . 2 ) and as such should 
provide for communications paths, motivation, and shortened communications distances. 

Planning is the key to a successful technology transfer. Today, even if the technology developer 
and the intended user agree that the transfer is advantageous to each side, the lack of clear 
planning and understanding of the questions to be addressed, leads to, at the very least, a 
difficult time, and often to failure. 

The Technology Transfer Process is depicted in Figure 13. This process addresses all the key 
factors described in the previous section: 

- Planning 
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- User involvement 


- Communications 

- A process is required 

- Knowing and asking the right questions 

- Responsibility and accountability and 

- Funding. 

Each annual cycle starts with a review of inputs: 

(1) the current program (on-going programs with their Technology Transfer Plan, and 
the current mission set), 

(2) new requirements (input is based on future missions), 

(3) new technologies (inputs consists of JPL thrusts, technology forecasts, and 
technology needs based on the future missions), and 

(4) new out-year plan and schedule (inputs are all of the above). 

The results of this review may be any of the following (based on the inputs) 

• termination of an on-going program (destination the “86"-trash can). 

• modification of an on-going program in the light of new missions, new requirements, 

and/or new technologies. 

• standard continuation of current effort (probably with minor updates to the 

Technology Plan). 

• initiation of a new technology transfer effort. 

• end user acceptance of the technology! 

A standard output each year is the forecast of upcoming technology transfer candidates on the 5 
to 7 year horizon. This output provides a context and some continuity to the whole transfer as a 
set of activities. 

The identification of a new candidate initiates a technology transfer cycle. After selection of 
accountable advocates (champions) two activities are started: writing the Technology Transfer 
Plan and preparation of a Technology Readiness Review. Besides the questions listed in Figures 
14 and 15, the Technology Readiness Review will address issues such as: 

• Basic concepts and technology associated with the transfer 

• Mission requirements with derived requirements for this transfer 

• State-of-practice contrasted with the state-of-art. 
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• Acceptance and success criteria for the receiver {host project). 

• State of the technology development including proof-of-concept demonstrations, etc. 

• Risk and affordability with respect to current technology and the needs of the intended 
users. 

• Does the technology meet the needs of the intended receiver? What is paramount - 
performance? lifetime? reliability? mailability? ..other “-ilities"? 

• Summary of accomplishments, identified issues and potential risks. 



Figure 13 Technology Transfer Process 

The result of the Readiness Review should be permission to proceed. It is here that any special, 
consideration should be documented, i.e. the need to proceed while keeping a backup position in a 
viable state. Readiness does not just refer to the technology but also the the intended user. That 
is to say that the needs of the ultimate user and the technology match or that they will actually 
use the technology! 
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- What impact can this technology offer our program/project? 

• What are the costs/risks associated with introducing this technology? 

- Where does this technology rank in importance to our program/project needs? 

• Is there a plan to receive the technology In a timely fashion? 

- Are there adequate resources to receive and develop the technology? 

- What will be done to upgrade the staff, if that is necessary? 

- Is there a champion/advocate for this technology? Is that person at the right level? 

- Have we done an adequate job of sharing the program/project opportunities with the research 

organization? 

• Does the giver have an understanding of the timing of our needs? 

- Have we agreed on what constitute a demonstration of technical feasibility? 

• What has been the history of the relationships between these two organizations? If there is a 

history, what are the strengths upon which to capitalize? 


Figure 14 Checklist for the Receivers 11 


- What does the technology promise? 

- How do the promises related to the program/project needs? 

- What are the costs/ risks associated with developing the technology? 

- How is industry using this technology? 

• Is the technology famiiiar/unfamiliar to the receiver? 

- Where does this technology rank in importance to the receiver? 

- Is there adequate technical expertise to pick up the research? 

- If not, is there any training or recruiting support we can provide? 

- Is management in the project/program committed to the technology? 

• Have we adequately marketed the technology? 

- Do the researchers have a comprehensive understanding of the program/projecfs needs and 

opportunities? 

• Are there adequate resources to research? To transfer the technology? 

- What documentation does the receiver need? Has it be produced? 

• Is there a plan to deliver the technology is a timely fashion? 

• What is the proper hand-off of this technology? 

- Have responsibilities been mutually delineated and accepted? 

- Has the information exchange been thorough and timely? 


Figure 15 Checklist for the Givers 12 


11 “A Study of the Factors Which Affect Technology Transfer in a Multilocation Multibusiness 
Unit Corporation", M. L. Ounjian and E. B. Came, IEEE Transactions on Engineering 
Management, Vol EM-34, No. 3, August 1987, pp. 194-201. 

12 Ibid. 
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3.2 The Plan 


With the goals defined, the technology transfer advocates derive a detailed plan from a general 
ordered outline. This Technology Transfer Plan (see Figure 16 for the outline) is a management 
artifact. Its purpose is to establish ownership of the transfer of technology between peer 
organizations, i.e. a peer-to-peer process. This plan will also serve as a driver, check list, and 
guide, especially since each task description explicitly relates schedule and responsible person. 
In essence, this plan documents the effort, discipline, rigor, and order that are necessary to 
make it all come together. 

The authors of the plan are the two advocates. Approval includes: advocates, program office(s), 
deveioping.organization(s). 

4.0 Summary 

The problems associated with technology transfer are complex. Some of the Do's for a 
successful collaboration and hence a successful technology transfer include:^ 

• Treat the technology transfer as a personal commitment. It is people that make 

partnerships work. 

• Anticipate that it will take up management time. If you can not spend the time, do not 

start the transfer. 

• Mutual respect and trust are essential. If you do not trust the people you are working 

with, forget it. 

• Remember that both partners must get something out of it. Mutual benefit is vital. 

This will probably mean that you have got to give something up. Recognize this at the 
outset. 

• Do not put off resolving unpleasant or cont entious Issues until “later". 

• Recognize that during the course of the transfer/collaboration, circumstances and 

markets change. Recognize your partner’s problems and be flexible. 

• Make sure that you and your partner have mutual expectations of the transfer and its 

time scale. 

• Get to know your opposite numbers at all levels. 

• Appreciate the cultural differences. Do not expect a partner to act or respond 

identically to you. 

• Recognize your partner's interests and independence. 


Each technology transfer is unique, and as such, requires careful planning. At the least, this 
planning must detail (1) the technology to be transferred, (2) the readiness of this technology, 


13 “The Global Logic of Strategic Alliances", K. Ohmae, Harvard Business Review, vol 67, No. 2 
(March/April), pp. 143-154. 
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(3) the needs of the intended users, (4) the process and schedule for the transfer, and (5) the 
acceptance criteria of the user (i.e. how do we know when the process has been successful?). 

The basic dimensions of motivation - the organizations and individual, communications between 
the technology developers and intended users, organizational complexities, and maturity of 
technology, itself, provide a rich base of solutions. These dimensions lead to essential factors 
requiring attention are planning, user involvement, communications, a process, knowing and 
asking the appropriate questions, assigning responsibility and accountability and finally, 
recognition that little is accomplished without adequate funding. 

The detailed solutions just compliment the key factors (listed above). These factors are 
embodied in the steps of the process that is described in Section 3.1. 
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Section # Title 

1.0 Introduction 

1.1 Identification 

1.2 Overview 

1 .3 Document Scope 

1.4 Controlling Documents 

1 .5 Applicable Documents 

2.0 Organization and 

Responsibilities 


3.0 Polices and Constraints 

3.1 Project Polices 

3.2 Project Standards 


4.0 Technical Approach 

4.1 Work Inputs 


4.2 Technical Constraints 

4.3 Deliverables 


5.0 Methods, tools, and training 


6.0 Metrics Reporting 


Appendix A Glossary 
Appendix B Acronyms 
Appendix C Budget 
Appendix D Schedules 


Description 
Project name 

Brief description of the Project. Brief 
statement of what this Technology does. 
What this document addresses and how it 
relates to other documents 
Documents that control this document 
Documents referenced by this document 
The TTP shall provide definition of roles and 
responsibilities of personnel and their 
relationships. Show the project 
organization chart. Show an activity or 
product-oriented work breakdown 
structures with a mapping to the 
organization chart. 

Polices to be applied to this work 
Identify JPL and other standards that are to 
be used. Describe the milestone reviews. 
Specify the convening authority for each 
review. 

Describe all inputs from other 
organizational elements. Identify source, 
need date, acceptance criteria. 

Definition and scope of the work to be 
accomplished. Identify products to be 
delivered. 


Identify the management methods to be 
applied tor resource monitoring and 
control, configuration management, and 
product assurance. Include regularly 
scheduled development status reviews. 

Specify data to be reported to monitor work 
accomplished, resources consumed, 
products generated, and problems 
encountered for each phase of 
development. 


Figure 16 Transfer Plan Outline 
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Appendices 


Probability ftf Communlftatlon In QroanlzatlQM o^hahllitlec of 

in Manaaina the Row of Technology there were three charts depicting the Probabilities of 
communication between people under differing circumstances. These are reproduce 

... „ O , lie Probability Thai Two I'eople Will Communicate a> a Function 
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Technology Readiness Levels Descriptions 


Level 1 Basic Principles Observed and Reported • Preliminary efforts are expended to identify 
the new technology and its applicability, and to provide a mathematical, empirical, or 
other supportive, basis to believe in the successful creation of the technology. 

Level 2 Technology Concept and/or Application Formulated • Based upon preliminary work, the 
concept for the technology is evolved to specification of components, limits, and 
capabilities. 

Level 3 Analytical and Experimental Critical Function and/or Characteristic Proof-of-Concept 

- The elements which make up the technology are constructed. In a piecewise fashion, 
each required function is created and tested. 

Level 4 Component and/or Breadboard Validation in Laboratory Environment • Each element is 
integrated into a demonstration of the technology y. While limited in scope, application 
or performance, the breadboard serves to prove the feasibility of pursuing the 
development. The breadboard also helps to identify limitations, errors in components 
and, perhaps, flaws in the basic theory or empirical studies. 

Level 5 Component and/or Breadboard Validation in a Relevant Environment (Ground or Space ) 

- Following successful breadboarding, a prototype for the the technology is constructed 
and tested in the working environment. This level serves to affirm that the basic 
theories and motivations for the technology are correct. 

Level 6 System/Subsystem Model or Prototype Demo in a Simulated Environment (Ground or 
Space ) • Sometimes the prototype is transitioned into a ground qualified application of 
the technology. Tested in an operational environment, the proof-of-concept model is 
used to assure that no major technological flaws exist which might limit or jeopardize 
the operational use of the technology. 

Level 7 System Prototype Demonstration in a Space Environment - When appropriate, the 
ground qualified unit is test during spaceflight. This is the ultimate check that the 
technology and its embodiment are correct for the intended function in the spacecraft 
application. 

Level 8 Actual System Completed and “Flight Qualified” Through Test and Demon (Ground or 

Space) • Given correct operation during qualification, the embodiment of the technology 
is placed into operational status. Operational status primarily assures future users that 
there is little or nor manageable risk in applying the new technology and that the cost of 
implementation and operation/maintenance is reasonably understood. 

Level 9 Actual System “Flight Proven” Through Successful Mission Operations - Common 
usage. 
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